Коллега с virten.net написал замечательную статью об использовании сетевых адаптеров USB на хостах VMware ESXi, основные моменты которой мы приведем ниже.

Напомним, что подключить сетевые адаптеры USB на хостах ESXi можно с помощью драйвера USB Network Native Driver for ESXi, о котором мы не так давно писали вот тут. Такой адаптер, например, можно использовать, когда вам необходимо подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов.

Еще один вариант использования таких адаптеров - когда у вас (например, на тестовом сервере) есть всего один гигабитный порт, а вам нужно тестировать технологии и продукты, где нужно несколько высокоскоростных соединений.

Итак, после того, как вы скачаете драйвер, его установка делается одной командой:

# esxcli software vib install -d /path/ESXi700-VMKUSB-NIC-FLING-39035884-component-16770668.zip

На VMware ESXi 7 можно использовать фичу "component":

# esxcli software component apply -d /path/ESXi700-VMKUSB-NIC-FLING-39035884-component-16770668.zip

С помощью PowerShell можно создать кастомизированный образ ESXi с уже вшитым драйвером сетевого USB-адаптера. Просто раскомментируйте строчку с нужной версией драйвера:

# ESXi 7.0 Image with USB NIC Fling 1.6:
$baseProfile = "ESXi-7.0.0-15843807-standard"   # See https://www.virten.net/vmware/vmware-esxi-image-profiles/ for available Image Profiles

$usbFling = "ESXi700-VMKUSB-NIC-FLING-39035884-component-16770668.zip"        # Uncomment for ESXi 7.0

#$usbFling = "ESXi670-VMKUSB-NIC-FLING-39203948-offline_bundle-16780994.zip"  # Uncomment for ESXi 6.7

#$usbFling = "ESXi650-VMKUSB-NIC-FLING-39176435-offline_bundle-16775917.zip"  # Uncomment for ESXi 6.5
Add-EsxSoftwareDepot https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

Export-ESXImageProfile -ImageProfile $baseProfile -ExportToBundle -filepath "$($baseProfile).zip"

Remove-EsxSoftwareDepot https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

Invoke-WebRequest -Method "GET" https://download3.vmware.com/software/vmw-tools/USBNND/$($usbFling) -OutFile $($usbFling)

Add-EsxSoftwareDepot "$($baseProfile).zip"

Add-EsxSoftwareDepot $usbFling

$newProfile = New-EsxImageProfile -CloneProfile $baseProfile -name $($baseProfile.Replace("standard", "usbnic")) -Vendor "virten.net"

Add-EsxSoftwarePackage -ImageProfile $newProfile -SoftwarePackage "vmkusb-nic-fling"

Export-ESXImageProfile -ImageProfile $newProfile -ExportToIso -filepath "$($baseProfile.Replace("standard", "usbnic")).iso"

Export-ESXImageProfile -ImageProfile $newProfile -ExportToBundle -filepath "$($baseProfile.Replace("standard", "usbnic")).zip"
 

При установке VMware ESXi на хост, где есть только USB сетевые адаптеры, процесс может зависнуть на 81%. В этом случае почитайте вот эту статью.

Кстати, ваши USB-адаптеры лучше всего пометить наклейками. Автор предлагает указать имя хоста ESXi, MAC-адрес адаптера и его номер vusbX:

Номер виртуального vusbX не сохраняется при перезагрузках. Начиная с версии драйвера 1.6 можно закрепить MAC-адрес за нужным vusbX. Сначала найдем наш адаптер:

# esxcli network nic list |grep vusb |awk '{print $1, $8}'

vusb0 00:23:54:8c:43:45

vusb1 a0:ce:c8:cd:3d:5d

Затем сделаем статический маппинг адаптеров с использованием модуля vmkusb_nic_fling:

# esxcli system module parameters set -p "vusb0_mac=00:23:54:8c:43:45 vusb1_mac=a0:ce:c8:cd:3d:5d" -m vmkusb_nic_fling

В данной команде нужно перечислить все адаптеры через пробел (если вы вызываете ее второй раз, то нужно переуказать каждый из адаптеров, иначе маппинг сбросится).

Далее нужно проверить маппинги с помощью команды:

# esxcli system module parameters list -m vmkusb_nic_fling
Name                        Type    Value              Description
--------------------------  ------  -----------------  -----------
usbCdromPassthroughEnabled  int                        Enable USB CDROM device for USB passtrough: 0 No, 1 Yes
vusb0_mac                   string  00:23:54:8c:43:45  persist vusb0 MAC Address: xx:xx:xx:xx:xx:xx
vusb1_mac                   string  a0:ce:c8:cd:3d:5d  persist vusb1 MAC Address: xx:xx:xx:xx:xx:xx
vusb2_mac                   string                     persist vusb2 MAC Address: xx:xx:xx:xx:xx:xx
vusb3_mac                   string                     persist vusb3 MAC Address: xx:xx:xx:xx:xx:xx
vusb4_mac                   string                     persist vusb4 MAC Address: xx:xx:xx:xx:xx:xx
vusb5_mac                   string                     persist vusb5 MAC Address: xx:xx:xx:xx:xx:xx
vusb6_mac                   string                     persist vusb6 MAC Address: xx:xx:xx:xx:xx:xx
vusb7_mac                   string                     persist vusb7 MAC Address: xx:xx:xx:xx:xx:xx

Если вы хотите сделать текущий маппинг постоянным, то используйте команду:

# esxcli system module parameters set -p "$(esxcli network nic list |grep vusb |awk '{print $1 "_mac=" $8}' | awk 1 ORS=' ')" -m vmkusb_nic_fling

Также статические маппинги можно сделать и через PowerCLI. Выводим адаптеры:

PS> Get-VMHostNetworkAdapter -VMHost esx2.virten.lab -Physical -Name vusb* |select Name,Mac 

Name  Mac

----  ---

vusb0 00:23:54:8c:43:45

vusb1 a0:ce:c8:cd:3d:5d

Настраиваем маппинги MAC-адресов:

PS> get-vmhost esx2.virten.lab | Get-VMHostModule vmkusb_nic_fling | Set-VMHostModule -Options "vusb0_mac=00:23:54:8c:43:45 vusb1_mac=a0:ce:c8:cd:3d:5d"
 

Проверяем результат:

PS> get-vmhost esx2.virten.lab | Get-VMHostModule vmkusb_nic_fling |ft -AutoSize

  Name             Options

  ----             -------

vmkusb_nic_fling vusb0_mac=00:23:54:8c:43:45 vusb1_mac=a0:ce:c8:cd:3d:5d

Тестируем производительность адаптеров

В тесте используются три типа адаптеров на хосте ESXi:

• Intel NUC embedded NIC (подключен к физическому коммутатору)
• 1 Gbit StarTech USB NIC (подключен к физическому коммутатору)
• 2.5 Gbit CableCreation (кросс-соединение между хостами)

Измеряем задержки (latency) с помощью пинга (50 штук):

# ping [Address] -c 50

Результат:

Далее тестируем пропускную способность (bandwidth) с помощью iperf3. Для этого нужно сделать копию бинарника утилиты:

# cp /usr/lib/vmware/vsan/bin/iperf3 /usr/lib/vmware/vsan/bin/iperf3.copy

Запускаем сервер на первом ESXi:

# /usr/lib/vmware/vsan/bin/iperf3.copy -s

Далее запускаем клиент на втором ESXi. Тест идет 5 минут (300 секунд) с сэмплами каждые 10 секунд:

# /usr/lib/vmware/vsan/bin/iperf3.copy -i 10 -t 300 -c [SERVER-IP]

Результат:

Далее проводим операцию vMotion виртуальной машины между хостами ESXi. Результат таков:

Очевидно, кросс-соединение на адаптерах 2.5G рулит.

Проверка совместимости

Не все сетевые адаптеры USB поддерживаются нативным драйвером. Их актуальный список всегда можно найти вот тут. Вот эти адаптеры точно работают:

Адаптеры доступны в форм-факторах USB-A и USB-C. Между ними есть переходники.

Если вам нужно высокоскоростное соединение (multi-gigabit) между несколькими хостами, можно посмотреть на следующие коммутаторы:

• MikroTik CRS305-1G-4S+IN ($130 USD) - 4 порта
• MikroTik CRS309-1G-8S+IN ($260 USD) - 8 портов
• Netgear MS510TX ($260 USD) - 10 портов
• TRENDnet TEG-30102WS ($450 USD) - 10 портов

Самое быстрое и дешевое соединение между двумя хостами ESXi - соединить адаптеры патч-кордом напрямую:

Проверяйте параметр MTU size, когда включаете Jumbo Frames

Если вы меняете размер MTU на виртуальном коммутаторе, он принудительно меняется на всех подключенных к нему физических сетевых адаптерах. Имейте в виду, что эти адаптеры должны поддерживать выставляемый MTU size.

Посмотреть размер MTU можно следующей командой:

[root@esx4:~] esxcfg-nics -l
Name    PCI          Driver      Link Speed      Duplex MAC Address       MTU    Description
vmnic0  0000:00:1f.6 ne1000      Up   1000Mbps   Full   00:1f:c6:9c:47:13 1500   Intel Corporation Ethernet Connection (2) I219-LM
vusb0   Pseudo       uether      Up   1000Mbps   Full   00:24:9b:1a:bd:18 1600   ASIX Elec. Corp. AX88179
vusb1   Pseudo       uether      Up   1000Mbps   Full   00:24:9b:1a:bd:19 1500   ASIX Elec. Corp. AX88179

В данном примере MTU size настроен как 1600, что подходит для адаптеров (и работает для сети NSX-T). Если же вы поставите его в 9000, то увидите в vmkernel.log ошибки для dvSwitch о том, что такой размер не поддерживается устройством:

2020-07-19T16:10:42.344Z cpu6:524356)WARNING: vmkusb: Set MTU 9000 is not supported: Failure
2020-07-19T16:10:42.344Z cpu6:524356)WARNING: Uplink: 16632: Failed to set MTU to 9000 on vusb0

Если вы хотите проверить корректность вашего MTU size, то можно использовать команду ping с размером пакета MTU-28 байт (8 байт на заголовок ICMP и 20 байт на заголовок IP). Таким образом, для MTU size 1600 используйте число 1572:

[root@esx2:~] vmkping ++netstack=vxlan 192.168.225.10 -d -s 1572 -I vmk10
PING 192.168.225.10 (192.168.225.10): 1572 data bytes
1580 bytes from 192.168.225.10: icmp_seq=0 ttl=64 time=0.680 ms

[root@esx2:~] vmkping ++netstack=vxlan 192.168.225.10 -d -s 1573 -I vmk10
PING 192.168.225.10 (192.168.225.10): 1573 data bytes
sendto() failed (Message too long)

Источник статьи.

На днях состоялся релиз интересного продукта Project Antrea 0.9.1, который позволяет пользователям кластеров Kubernetes на платформе VMware управлять сетевым взаимодействием контейнеров на базе политик.

Ну а VMware Container Networking with Antrea - это новый коммерческий продукт на базе Project Antrea, представляющий собой решение для публичных и частных облаков, использующих Open vSwitch, которое позволяет управлять сетевым взаимодействием на нескольких уровнях с предоставлением поддержки со стороны VMware. Он реализует следующие функции в рамках среды Kubernetes:

1. Исполнение политик для Managed Kubernetes Services

Antrea добавляет официальную поддержку служб AWS EKS. Кроме того, Antrea улучшает поддержку сервисов Azure AKS с использованием CNI chaining и режимом трафика "networkPolicyOnly" с соблюдением политик при использовании нативного соединения.

Также решение Antrea имеет поддержку Google GKE и может быть использовано как primary CNI в Amazon и Azure для решения проблемы исчерпания IP-адресов в окружении с большим количеством небольших нагрузок в контейнерах.

2. Политики ClusterNetworkPolicy

В отличие от политик Kubernetes network policies, которые привязаны к пространствам имен, политики ClusterNetworkPolicy позволяют администраторам определять их в рамках нескольких неймспейсов. Эти политики можно упорядочивать и добавлять к ним различные действия, что упрощает применение политик как к кластеру в целом, так и к его частям.

3. Разделение политик на уровни

В Antrea есть глобальные политики (а в будущем будут нативные политики уровня неймспейсов), которые можно сгруппировать в ярус политик (policy tier). Сейчас есть 5 таких статических ярусов: Emergency, SecurityOps, NetworkOps, Platform и Application.

В будущих релизах пользователи смогут создавать кастомные ярусы и задавать порядок их подчинения. Ролевая модель Kubernetes RBAC обеспечивает контроль создания политик пользователями. Администраторы информационной безопасности могут делегировать права по созданию политик разработчикам, при этом глобальные политики остаются на контроле администраторов ИБ.

4. Улучшения мониторинга и диагностики

Antrea предоставляет набор диагностических и операционных метрик за счет средств мониторинга Prometheus и предоставляет нативные определения CustomResourceDefinitions (CRDs), чтобы наблюдать и диагностировать состояния компонентов инфраструктуры Antrea и потоков данных.

Например, Traceflow позволяет операторам проводить инъекции пакетов в данные контейнеров, чтобы убеждаться в исполнении сетевых политик, маршрутизации и эффектов инкапсуляции для трафика между сайтами. Также утилита antctl может генерировать саппорт-бандлы для диагностики проблем.

5. Интеграция NSX-T и VMware Container Networking

Решение VMware NSX-T - это полноценная платформа для сетевой защиты приложений в контейнерах, виртуальных машин и невиртуализованных нагрузок. VMware Container Networking with Antrea работает в тандеме с NSX-T, чтобы обеспечить бесшовную сетевую связность и контроль исполнения сетевых политик в кластерах Kubernetes в виртуальном датацентре.

Более подробно о решении VMware Container Networking with Antrea рассказано на этой странице.

На сайте проекта VMware Labs появился еще один интересный виртуальный модуль (Virtual Appliance) - утилита Software-Defined Data Center Skywalk. С помощью нее администраторы распределенной инфраструктуры виртуальных датацентров могут организовать VPN-сеть между ними и синхронизировать политики распределенных сетевых экранов.

Обычно работа через интерфейсы консолей или API в разных датацентрах VMC SDDC требует установления отдельных VPN-соединений. Утилита SDDC Skywalk позволяет автоматически обнаружить, зарегистрировать и подключить VPN между датацентрами VMware vCloud в один клик.

Также посредством данной утилиты политики Distributed Firewall (DFW) для выбранных сервисов автоматически синхронизируются с онпремизного датацентра (локальный NSX-T) в облако с минимальным участием пользователя.

Скачать SDDC Skywalk можно по этой ссылке. Инструкция по использованию доступна здесь.

Как вы знаете, в продуктовой линейке VMware есть два решения, предназначенных для виртуализации сетей и централизованного управления сетевым взаимодействием виртуальных машин на уровне всего датацентра - это продукты NSX-T и NSX-V.

NSX-T предназначен для гибридных окружений, как в смысле поддержки разных гипервизоров (ESXi и KVM), так и в плане поддержки облачных инфраструктур (например, AWS). Решение NSX-V разработано специально для виртуальной среды VMware vSphere и использует виртуальные коммутаторы vSphere Distributed Switch (vDS). Оба решения могут быть использованы под одной лицензией, что дает пользователям гибкость при выборе нужного типа развертывания.

(картинка отсюда)

Давайте взглянем на сравнительную таблицу двух версий решений VMware NSX, где собраны основные ключевые отличия:

Ну и вот обзорное видео об основных отличиях NSX-T и NSX-V:

Компания VMware недавно выпустила интересную бесплатную книгу "Micro-segmentation for Dummies Guide, 2nd Edition".

Те из вас, кто использует решение для сетевой виртуализации и агрегации трафика VMware NSX и средство обеспечения сетевой безопасности vRealize Network Insight, знают о таком подходе как микросегментация. С помощью него можно управлять сетевыми политиками на базе контекстов приложений - сетевом (на уровне 7 модели OSI), пользовательском (ID, сессия RDSH и прочее), а также рабочей нагрузки (тэги, группы безопасности).

Данная модель позволяет контролировать сетевой трафик на более гранулярном уровне, чем на уровне виртуальных машин и модулей Virtual Appliance, а также существенно повышает безопасность коммуникаций за счет принципа выдачи наименьших привилегий и фаерволлинга на уровне микросегментов.

Из книжки вы узнаете:

• Как разработать архитектуру защищенного датацентра на базе сетевой виртуализации и фаерволлинга на уровне рабочих нагрузок.
• Как микросегментация позволяет предотвратить распространение скрытых угроз в инфраструктуре датацентра.
• Топ 10 бизнесовых и функциональных преимуществ микросегментации.

Скачать книгу "Micro-segmentation for Dummies Guide, 2nd Edition" можно по этой ссылке.

Оказывается, на ресурсе VMware Techzone есть не только образовательные материалы, но и полезные утилиты, в частности, VMware Digital Workspace Topology Design Tool. С помощью этого средства администратор может выбрать имеющиеся у него компоненты решений VMware Workspace ONE и VMware Horizon, а также указать вариант развертывания - и нарисовать архитектурную диаграмму сетевой инфраструктуры.

Чтобы получить доступ к этой утилите, переходим по данной ссылке и в разделе Architect and Integrate кликаем по ссылке Launch для виджета Digital Workspace Topology Tool:

После этого нас попросят авторизоваться с кредами My VMware или Partner Portal и попросят ввести название профиля:

Далее нужно выбрать компоненты инфраструктуры Workspace ONE, которые будут использоваться для построения архитектуры (то есть те, которые вы планируете развертывать):

Дальше нужно указать уже компоненты инфраструктуры Horizon, для варианта On-Premises нужно выбрать составляющие решения Horizon 7 в инфраструктуре на вашей площадке:

В итоге вы получите результат с архитектурой сетевой инфраструктуры:

Также вы можете отобразить отчет по необходимым для открытия портам сетевых экранов, через которые осуществляется взаимодействие между компонентами:

Также можно и сохранить полученную конфигурацию в своем профиле (иконка с дискетой).

Это пост нашего спонсора - компании ИТ-ГРАД, предлагающей услугу аренды виртуальных машин из облака. Каждый клиент «ИТ-ГРАД», приобретая услугу IaaS, получает не просто виртуальные машины в нашем облаке, а настоящий виртуальный дата-центр, где можно организовать сетевую связность согласно требованиям вашего проекта...

На днях на сайте проекта VMware Labs появилась полезная администраторам vSphere штука - утилита vSphere Replication Capacity Planning, позволяющая определить реальное потребление трафика репликации виртуальными машинами и размер передаваемой дельты данных. Это позволяет планировать сетевую инфраструктуру и принимать решения о выделении канала еще до того, как вы включите репликацию для всех своих виртуальных машин.

Утилита Replication Capacity Planning показывает графики, касающиеся объема передачи сетевого трафика LWD (lightweight delta - изменения с момента последней репликации) во времени, а также метрики по размеру дельты в различных временных масштабах - часы, дни, недели и месяцы.

Также в результате работы этого средства для виртуальной машины будет показано, какой объем вычислительных ресурсов и хранилища под реплики вам потребуется на целевой площадке (без учета актуальной политики хранилищ там):

Решение vSphere Replication Capacity Planning развертывается как виртуальный модуль (Virtual Appliance), для его работы потребуется VMware ESXi 6.0 или более поздней версии. Скачать его можно по этой ссылке. Документация доступна здесь.

На днях компания VMware выпустила большое обновление свой платформы для сетевой виртуализации датацентров NSX-T 3.0. Напомним, что это решение предназначено для сетевой виртуализации и агрегации виртуальных сетей датацентров, работающих на базе гибридной среды гипервизоров и контейнеров приложений Kubernetes/Docker. О версии NSX-T 2.5, выпущенной в рамках VMworld 2019, мы писали вот тут.

Давайте посмотрим, что нового в обновленном NSX-T 3:

1. Улучшения работы в облачной среде.

Здесь можно отметить следующие нововведения:

• NSX Federation - с помощью нового компонента NSX Global Manager можно централизованно управлять распределенной виртуальной сетью в нескольких локациях, поддерживая их в синхронизированном виде с точки зрения конфигурации, политик безопасности и операционного управления. При миграции рабочих нагрузок между датацентрами их политики сохраняются и контролируются из единой точки.

• Поддержка AWS GovCloud и Azure Government - эта возможность позволяет обслуживать облака на базе AWS и VMware для госструктур США с соблюдением всей необходимой регуляторики.
• Улучшенная поддержка нескольких клиентов в облаке за счет VRF Lite и Layer 3 BGP EVPN. Средства VRF Lite позволяют упростить управление сетевой средой каждого клиента за счет поддержания для него отдельной таблицы маршрутизации, а Layer 3 EVPN бесшовно соединяет сети телеком-провайдеров с оверлейными сетями.
• Dynamic Network Service Chaining - службы NSX service insertion теперь поддерживают механизм dynamic service chaining для трафика ВМ, контейнеров и физических серверов.

2. Улучшения безопасности.

Механизм Service-defined Firewall был значительно улучшен и теперь доступны следующие новые возможности:

• NSX Distributed IDS/IPS – это расширенный механизм обнаружения вторжений для трафика east-west в мультиоблачных окружениях на уровне 7 модели OSI. Этот механизм использует знания о природе систем и характере обмена трафиком между ними, что позволяет создавать виртуальные защищенные сетевые зоны без необходимости физической изоляции зон друг от друга.

• Улучшения L7 Edge Firewall – сетевой экран Layer 7 Edge Firewall приобрел функции анализа URL в рамках механизма URL Classification and Reputation.
• DFW для Windows 2016 – теперь распределенный фаервол (DFW), помимо поддержки Linux, поддерживает и физические серверы Windows 2016. 
• Правила на базе времени и мастер настройки микросегментации - теперь правила фаервола можно привязать ко временным окнам, определенным администратором. Также новый мастер настройки упрощает конфигурацию микросегментации на базе сетей VLAN.

3. Сетевое взаимодействие для виртуальных машин и контейнеризованных приложений.

• NSX-T полностью поддерживает инфраструктуру среды контейнеризованных приложений vSphere with Kubernetes. В единой среде контейнеров и виртуальных машин поддерживается маршрутизация, сетевое экранирование, балансировка нагрузки, NAT, IPAM и другие сетевые сервисы.

Вот как это работает в деталях:

• Возможность изоляции пространств имен vSphere Namespaces - теперь в NSX-T есть логика для автоматической реализации логических сегментов с маршрутизацией и сетевым экраном, а также сервисами IPAM для изоляции пространств имен в кластере vSphere Supervisor Cluster. Все рабочие нагрузки, созданные в пространстве имен, автоматически наследуют политики безопасности этого неймспейса.
• Интеграция с Cluster API в VMware Tanzu Kubernetes Grid Service – решение NSX-T интегрируется с данными службами, позволяя разработчикам развертывать кластеры Tanzu Kubernetes Grid. Там можно создавать логические сегменты, шлюз Tier-1 Gateway, балансировщики нагрузки и прочие вещи, необходимые для этих кластеров.

• Поддержка модулей Terraform Provider и Ansible - теперь поддерживаются расширенные рабочие процессы различных топологий для функций логического сегментирования, шлюза, а также сетевого оверлея и сегментов VLAN.
• Упрощенная интеграция с решением vRealize Network Insight 5.2 - это позволяет организовать end-to-end  видимость сетевых потоков, а также проводить более эффективный траблшутинг из дэшборда vRealize Network Insight. Также улучшены функции обнаружения приложений на платформах VMware.
• Улучшения OpenStack Neutron - плагин Neutron к NSX-T был существенно доработан. Это привело к улучшению механизма управления для нескольких NSX-T endpoints. Также оператор может теперь настраивать дополнительные параметры IPv6 (DHCPv6, IPv6 LB и NAT64).

Полный список нововведений VMware NSX-T 3.0 приведен в Release Notes. Скачать это решение по этой ссылке.

Как знают многие администраторы, во время установки vCenter Server Appliance (vCSA) для управления виртуальной инфраструктурой изменить MAC-адрес управляющего сервера нельзя - он генерируется при развертывании виртуального модуля установщиком и прописывается внутрь конфигурации. Между тем, если вам это все-таки по каким-то причинам требуется, Вильям Лам привел способ, как это сделать.

Ниже приведена процедура развертывания vCSA с сервера VMware ESXi.

Во-первых, надо преобразовать OVA-модуль в формат OVF, где можно будет потом изменить настройки. Делается это с помощью утилиты ovftool следующим образом:

ovftool --allowExtraConfig VMware-vCenter-Server-Appliance-6.7.0.42000-15132721_OVF10.ova VMware-vCenter-Server-Appliance-6.7.0.42000-15132721_OVF10.ovf

Сначала нам нужно добавить следующую конфигурацию в раздел Network конфигурации виртуального модуля OVF, содержащую нужный нам MAC-адрес:

<Item>

   <rasd:Address>00:50:56:ab:cd:ef</rasd:Address>

   <rasd:AutomaticAllocation>true</rasd:AutomaticAllocation>

   <rasd:Connection>Network 1</rasd:Connection>

   <rasd:ElementName xmlns:rasd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData">Ethernet adapter on &quot;Network 1&quot;</rasd:ElementName>
   <rasd:InstanceID xmlns:rasd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData">3</rasd:InstanceID>

   <rasd:ResourceSubType>vmxnet3</rasd:ResourceSubType>

   <rasd:ResourceType>10</rasd:ResourceType>

</Item>

Далее изменяем скрипт VCSAStaticMACAddress.sh на сервере ESXi, чтобы добавить туда нужные параметры вашего vCSA и начать его развертывание в вашей виртуальной среде. Для этого его нужно выполнить с параметром --injectOvfEnv, про который написано вот тут. Он позволяет внедрить свойства OVF в виртуальный модуль vCSA при его включении.

Если вы все сделали правильно, то сможете наблюдать за прогрессом развертывания вашего виртуального модуля из браузера по ссылке:

https://[адрес VCSA]:5480

В итоге вы должны увидеть, что в настройках модуля vCSA вы получили нужный вам MAC-адрес:

Если вы хотите пропустить стадию конфигурации сетевых настроек (IP-адрес и прочее) при исполнении скрипта, нужно выставить переменную VCSA_STAGE1ANDSTAGE2 в значение false. Тогда после развертывания модуля vCSA нужно будет закончить его конфигурацию по ссылке:

https://[адрес VCSA]:5480

После развертывания эта возможность будет доступна на открывшейся странице:

На сайте проекта VMware Labs обновился пакет USB Network Native Driver for ESXi до версии 1.4, который содержит в себе драйверы для сетевых адаптеров серверов, подключаемых через USB-порт. Такой адаптер, например, можно использовать, когда вам необходимо подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов.

Давайте посмотрим, что там появилось нового:

• Добавлена поддержка USB-устройств SuperMicro/Insyde Software Corp.
• Исправлена проблема больших кадров 9K Jumbo frames для устройств с чипсетом RTL8153.
• Устранена ошибка с неправильным отображением пропускной способности для некоторых устройств на дефолтной скорости.

Новые номера билдов теперь следующие:

• ESXi670-VMKUSB-NIC-FLING-33242987-offline_bundle-15615590.zip
• ESXi650-VMKUSB-NIC-FLING-33268102-offline_bundle-15620342.zip

Список поддерживаемых устройств на сегодняшний день выглядит так:

Скачать USB Network Native Driver for ESXi версии 1.4 можно по этой ссылке.

В конце ноября прошлого года мы писали о постерах, посвященных решению vRealize Network Insight и его очень широким возможностям поиска. Эти возможности позволяют находить нужные сущности и объекты в инфраструктуре VMware vSphere, NSX и прочих компонентах.

Вышедший в начале января постер vRealize Network Insight Search Poster for SD-WAN & VeloCloud показывает, какие поисковые шаблоны можно использовать для платформы SD-WAN (это технология купленной компании VeloCloud, которая реализует концепцию Software-Defined Networking в рамках WAN-сетей). Как некоторые из вас помнят, интеграция с решениями VeloCloud появилась в vRNI пятой версии.

Собственно, сам постер:

Второй интересный постер - это vRealize Network Insight Search Poster for Kubernetes. Он позволит вам найти объекты нативной инфраструктуры Kubernetes или развернутой на платформах VMware PKS или OpenShift.

Итого все постеры по функциям поиска в решении vRNI вы можете скачать по этим ссылкам:

• Kubernetes Search Poster
• SD-WAN & VeloCloud Search Poster
• NSX for vSphere Search Poster
• Network Flow Search Poster
• Virtual Machine Search Poster

Некоторые администраторы сталкиваются с такой конфигурацией виртуальной инфраструктуры, когда управляющий сервер VMware vCenter оказывается за NAT или сетевым экраном относительно части хостов VMware ESXi:

В этом случае получается добавить хосты ESXi в vCenter, но через примерно одну минуту они уходят в офлайн, при этом успешно пингуются. Также в течение этой минуты, пока они видны в vCenter, хосты не могут синхронизировать свою конфигурацию. Причина такого поведения проста - в агент vCenter на хостах ESXi (он же vpxa) прописывается внутренний адрес vCenter для связи со стороны ESXi.

Эти хартбиты идут на целевой порт 902 TCP/UDP (источник варьируется):

Если погуглить, то можно найти статью KB 1010652, где сказано, что такая конфигурация не поддерживается со стороны VMware.

Но есть обходной путь, который вполне работает у многих пользователей. Нужно открыть 902 порт на вашем фаерволе/NAT, а также поменять в файле конфигурации агента vCenter

/etc/vmware/vpxa/vpxa.cfg

строчку:

<serverIp>10.0.0.1</serverIp> на внешний IP-адрес вашего NAT-маршрутизатора. Также нужно добавить следующий параметр в этот файл, чтобы указанный IP не поменялся назад:

<preserveServerIp>true</preserveServerIp>

Перед редактированием файла vpxa.cfg нужно поменять права доступа командой:

chmod 744 /etc/vmware/vpxa/vpxa.cfg

а после редактирования вернуть их назад:

chmod 444 /etc/vmware/vpxa/vpxa.cfg

По окончании процедуры надо перезапустить management agents на хостах ESXi командой:

services.sh restart

И надо понимать, что данная конфигурация хоть и работает, но не поддерживается со стороны VMware. Официально для размещения vCenter за NAT workaround не существует.

На сайте проекта VMware Labs появилась еще одна интересная утилита - vCenter Plugin for vRealize Network Insight. С помощью данного плагина для управляющего сервера vCenter можно получить всю необходимую информацию от решения VMware vRealize Network Insight (vRNI) в консоль vSphere Client в виде отдельного раздела.

Это все позволяет администраторам виртуальной инфраструктуры VMware vSphere видеть информацию о сетевом взаимодействии в виртуальном датацентре и потоках виртуальных машин сразу в клиенте vSphere, без необходимости постоянно переключаться между двумя консолями:

Возможности плагина:

• Верхнеуровневый обзор активности vCenter: виртуальные машины, миграции vMotion и снапшоты.
• Отображение сетевой информации напрямую в vCenter:
  • Представление поведения внутреннего сетевого трафика east-west, сколько трафика расходуется.
  • Нарушение жизнедеятельности (хэлсчеков) для vCenter и прикрепленных к нему NSX-окружений.
  • Самые использующие сеть виртуальные машины, сгруппированные по именам, кластерам, сетям L2, подсетям, группам безопасности, паре источник-назначение, сети источник-назначение, IP-адресам источника и назначения.
  • Самые используемые сети.
  • Новые виртуальные машины, использующие интернет-трафик (полезно для обнаружения подозрительных активностей).
  • Топ-5 хостов и сетей, в которых наблюдается наибольшая потеря пакетов.
• Ссылка на консоль vRealize Network Insight, показывающие исходные данные и позволяющие глубже провалиться в детали. Можно применять фильтры, экспортировать данные и другое.
• Возможность настройки vCenter как источника данных и настройка NetFlow на доступных распределенных коммутаторах vSphere Distributed Switches.

Скачать vCenter Plugin for vRealize Network Insight можно по этой ссылке. Инструкции по развертыванию доступны тут.

В сентябре этого года мы писали о том, что компания VMware сделала доступным очень полезный онлайн-ресурс ports.vmware.com, в котором администраторы могут посмотреть порты и соединения для различных продуктов, таких как vSphere, vSAN, NSX и прочих. На тот момент на сайте было представлено всего 6 продуктов. С тех пор сайт регулярно обновлялся, и теперь пользователи VMware могут вывести таблицы портов уже по 12 решениям:

• vSphere
• vSAN
• NSX Data Center for vSphere
• vRealize Network Insight
• vRealize Operations Manager
• vRealize Automation
• vCloud Availability
• vCloud Usage Meter
• VMware HCX
• Horizon 7
• Workspace ONE Access
• Site Recovery Manager

В левой части можно выбрать один или несколько продуктов, для которых будут выведены все соединения с указанием портов, протокола и назначения взаимодействий с подробным описанием (а также направление взаимодействия). Это позволит правильно настроить сетевые экраны, через которые происходит коммуникация между компонентами виртуальной инфраструктуры.

Результаты можно экспортировать в отдельный красивый PDF-документ, либо распечатать. Что удобно, в колонке Version указана версия продукта, для которой эта информация актуальна. Обратите внимание также на гиперполезную функцию поиска по результатам вывода.

Пользуйтесь: https://ports.vmware.com

На днях на сайте проекта VMware Labs появилась очередная новая штука - средство Infrastructure Deployer for vCloud NFV, позволяющее в автоматическом режиме развернуть платформу VMware vCloud NFV (в издании NFV 3.2 VCD) и сконфигурировать ее. Напомним, что NFV - это комплексное решение по виртуализации сетевого стека для сервис-провайдеров (грубо говоря, замена аппаратных роутеров, сетевых экранов и прочих компонентов комплексом из виртуальных машин, предоставляющих динамические сетевые сервисы).

Сам рабочий процесс развертывания основан на архитектуре VMware vCloud NFV 3.0 Reference Architecture и предназначен только для инфраструктуры, развертываемой с нуля (то есть донастроить существующие компоненты не получится).

Сам продукт состоит из двух компонентов:

• Входной текстовый файл, в который нужно поместить данные об окружении и компонентах платформы vCloud NFV, которые необходимо развернуть.
• Скрипты PowerShell, которые будут исполнены в процессе развертывания.

Для запуска процедуры автоматизированного развертывания потребуется выполнение следующих условий:

• Работающий DNS-сервер.
• Все компоненты должны иметь актуальные FQDN в DNS.
• В инфраструктуре должен функционировать NTP-сервис.
• PowerShell не ниже 5.0 и PowerCLI не ниже 10.x.
• На Jump VM (там, где запускаются скрипты) должны быть установлены все последние обновления Windows.

Скачать Infrastructure Deployer for vCloud NFV можно по этой ссылке. Там же доступно развернутое руководство пользователя на 57 страницах.

В сентябре этого года мы рассказывали о возможностях новой версии решения для мониторинга и защиты сетевой составляющей виртуальной среды VMware vRealize Network Insight 5.0 (vRNI). Напомним, что это решение позволяет системным и сетевым администраторам (а также администраторам информационной безопасности) наблюдать за сетевым взаимодействием в рамках виртуальной инфраструктуры и предпринимать действия по ее защите.

В рамках прошедшего VMworld Europe 2019 компания VMware анонсировала обновление этой платформы - vRNI 5.1. Давайте посмотрим, что в этом решении появилось нового.

Во-первых, VMware продолжает улучшать функции SD-WAN, которые появились в продукте благодаря технологиям купленной компании VeloCloud. В духе фичи Virtual Network Assessment for NSX, версия vRNI 5.1 имеет функцию SD-WAN Assessment. Она анализирует трафик и данные из имеющейся невиртуализированной сети WAN и рассчитывает возврат инвестиций, если вы решите вложить деньги во внедрение решения SD-WAN.

Во-вторых, VMware добавила в vRNI новый дэшборд - VMware Cloud on AWS dashboard. Он позволяет вести мониторинг среды AWS в контексте концепции software defined data center (SDDC) и поддерживает компонент AWS Edge firewall, что дает возможности просмотра правил и их маппинга на сетевые потоки.

Третья интересная возможность vRNI 5.1 - функции для операций ежедневного обслуживания (Day-2 operation), такие как просмотр общего состояния инфраструктуры приложений, возможность просмотра упавших по скорости потоков, анализ трафика и другие средства, доступные в Application Dashboard.

Четвертая новая фича - поддержка физического NAT при анализе пути VM-VM, а также поддержка аппаратного Arista VTEP.

Ну и последняя новая возможность vRNI 5.1 - это улучшение функций для операций ежедневного обслуживания для решения VMware NSX-T, а также доработанные средства визуализации развернутых и затронутых изменениями компонентов.

Решение VMware vRealize Network Insight 5.1 пока нельзя скачать, но в скором времени VMware обещает его публичную доступность.

Перед самой конференцией VMworld 2019, которая прошла на прошлой неделе в Сан-Франциско, компания VMware анонсировала полезный сервис ports.vmware.com, где любой желающий может вывести порты и соединения по различным протоколам для следующих продуктов серверной линейки:

• vSphere
• vSAN
• NSX for vSphere
• vRealize Network Insight
• vRealize Operations Manager
• vRealize Automation

Выглядит это вот таким образом (кликабельно):

Как мы видим, в левой части можно выбрать один или несколько продуктов, для которых будут выведены все соединения с указанием портов и характера взаимодействий. Это позволит правильно настроить сетевые экраны, через которые происходит коммуникация между компонентами виртуальной инфраструктуры.

Результаты можно вывести в отдельный красивый PDF-документ, либо распечатать. Что удобно, в колонке version указана версия продукта, для которой эта информация актуальна.

Если раньше всю эту информацию приходилось вылавливать из статей базы знаний VMware, а также подглядывать в различные постеры, то теперь все очень удобно организовано на одном экране (и что важно с возможностью поиска по результатам). Также есть удобная функция - сортировка по колонкам, например, по номеру порта - когда хочется найти конкретный порт или диапазон.

В общем, пользуемся - ports.vmware.com.

Это гостевой пост нашего партнера - сервис-провайдера ИТ-ГРАД, предоставляющего в аренду виртуальные машины из облака по модели IaaS. Вспоминаем, кому пришлось столкнуться с неисправностями из-за проблем с Border Gateway Protocol. Приводим примечательные кейсы за последние несколько лет.

Весной этого года мы писали о новой версии продукта VMware vRealize Network Insight (vRNI) 4.1, который позволяет системным и сетевым администраторам (а также администраторам информационной безопасности) наблюдать за сетевым взаимодействием в рамках виртуальной инфраструктуры и предпринимать действия по ее защите.

На днях VMware объявила о выпуске vRNI 4.2, давайте посмотрим, что там появилось нового.

1. Новые Data Sources

Теперь данные можно получать из следующих систем:

• Fortinet Firewall

Можно получить полный доступ к средствам управления Fortinet FortiManager, который управляет сетевыми экранами FortiGate. Это позволяет видеть всю инфраструктуру в контексте фаерволов, мгновенно видеть, какие правила привязаны к ВМ, получать сетевую топологию и многое другое.

• OpenShift Container Platform

В прошлой версии была добавлена поддержка VMware Enterprise PKS и ванильной инсталляции Kubernetes, а теперь поддержка была расширена функциями сетевой видимости, средствами обеспечения безопасности приложений, планирования миграции и решения проблем для небольших нагрузок.

• Кастомные Data Sources

Это называется User Assisted Network Information (U-AN-I). В рамках этого механизма вы можете ввести информацию о собственном коммутаторе или маршрутизаторе, который в дальнейшем будет добавлен в список поддерживаемых устройств. Но еще до полноценной поддержки это даст вам возможность просматривать пути VM-to-VM, дэшборд для коммутатора/маршрутизатора в рамках сетевой топологии, список всех интерфейсов, маршрутов, список VRF и т.п.

Также есть Python-библиотека, которая позволит автоматизировать сбор информации с устройств (маршруты, интерфейсы и т.д.) и загрузить ее в Network Insight. Саму эту задачу можно добавить в планировщик для регулярного обновления.

2. Метрики Network Latency.

Network Insight 4.2 представляет метрику задержки в 2 формах: TCP Round-Trip Time (RTT), которая привязана к сетевому потоку и метрика latency между отдельными компонентами (виртуальные и физические адаптеры NIC в рамках хоста ESXi).

Метрика TCP RTT может быть найден на дэшборде потока:

Также можно найти все потоки, время RTT которых больше 10 мс, следующей командой в поиске:

Average Tcp RTT of flow where Average Tcp RTT > 10ms

Кроме того, есть еще один наглядный способ увидеть все сетевые потоки вашей инфраструктуры на одной странице - надо пойти в Flow Insights и выбрать диаграмму Network Performance:

Из этого представления вы сразу поймете, какие потоки отрабатывают с самой большой задержкой, после чего можно углубиться в структуру потока и понять причину, по которой эта задержка столь велика.

С точки зрения измерения latency между компонентами, сейчас доступны следующие связки: vNIC к pNIC, pNIC к vNIC и vNIC к vNIC.

Надо отметить, что для получения данной информации вам потребуется NSX Data Center for vSphere версии 6.4.5 или выше.

3. Новые функции Application Discovery.

В Network Insight 4.1 появилась возможность обнаружения приложений без использования агентов с помощью трех методов:

• Использование тэгов рабочей нагрузки (workload tags)
• Иморт приложений из ServiceNow CMDB
• Использование паттерн наименования (naming convention)

Последний метод особенно актуален для облачных систем (например, инстансы AWS EC2), поэтому раньше пользователи должны были сами конструировать регулярные выражения, что непросто.

Теперь же в мастере application discovery wizard для этого есть Pattern Builder:

Также, начиная с vRNI 4.2, вы можете сохранять  application discovery runs как шаблоны, чтобы не конструировать регулярные выражения заново, что очень удобно.

4. Улучшения дэшборда Application Dashboard.

Это лучший дэшборд vRNI, который показывает все потоки между всеми обнаруженными приложениями в вашей инфраструктуре. В версии vRNI 4.1 его возможности были несколько ограничены, теперь же каждый поток визуализуется и детализируется, когда вы увеличиваете диаграмму и масштабируете его.

При этом с увеличением конкретного компонента увеличивается степень детализации, то есть включаются все виртуальные машины, контейнеры и т.п.

Полный список улучшений и нововведений находится в Release Notes. Скачать vRealize Network Insight 4.2 можно по этой ссылке.

На днях VMware сделала анонс о завершении M&A-сделки по приобретению компании Avi Networks, которая занимается разработкой программного обеспечения в сетевой сфере, способствующего прозрачной доставке пользователям приложений в онпремизных и облачных датацентрах.

Цель приобретения - дополнить портфолио продукта NSX технологиями, которые позволяют создать multicloud network-virtualization overlay (NVO) на уровнях 2-7 в рамках законченной концепции SDN (software-defined networks).

Философия Avi Networks заключается в том, что частные облака должны оперировать с приложениями точно так же, как и публичные, обеспечивая переносимость машин и приложений между датацентрами вне зависимости от исходной ИТ-инфраструктуры каждого из них.

Основные фичи, которые предоставляет Avi Networks для облачных инфраструктур:

• Глобальный балансировщик для серверов на уровне датацентров
• Ускорение миграции и работы приложений
• Обеспечение защиты приложений при их миграции между облаками
• Обеспечение доступности приложений
• Мониторинг производительности и отчетность
• Обнаружение сервисов в датацентре
• Контейнеризация приложений на сетевом уровне (для миграции между датацентрами)
• Предоставление RESTful API для интеграции в существующую сетевую инфраструктуру датацентров

Некоторые компоненты Avi Networks, в частности балансировщик нагрузки, будут интегрированы в продукт VMware NSX, также само решение Avi Networks будет доступно как самостоятельный ADC-продукт для глобальной балансировки нагрузки, сетевого экранирования (Web application firewall, WAF) и расширенной аналитики и отчетности о сетевой инфраструктуре приложений датацентров.

Например, можно получить вот такой отчет об end-to-end коммуникации пользователей с приложением, визуализирующий время отклика на каждом из сетевых сегментов:

Более подробнее о приобретении Avi Networks можно узнать из этого поста в блоге VMware.

На сайте проекта VMware Labs появилось очередное обновление - стала доступна новая версия средства USB Network Native Driver for ESXi до версии 1.1. Напомним, что ранее мы писали о нем вот тут. Это нативный драйвер для сетевых адаптеров серверов, которые подключаются через USB-порт.

Такой адаптер можно использовать, когда вам необходимо, например, подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов. В каких-то еще случаях подключение такого адаптера может помочь, чтобы получить еще одно сетевое соединение без необходимости перезагружать сервер (и так же просто отключить его).

Новая версия драйвера содержит поддержку девяти новых устройств USB NIC, включая девайсы USB 2.0 RTL8152 & TPLINK. Полный список поддерживаемых устройств теперь таков:

Помимо этого, в драйвер также была добавлена поддержка Jumbo Frames (размером до 4K) для устройств RTL8153 и AX88179.

Для установки драйвера нужно развернуть на ESXi 6.5 или 6.7 один из двух VIB-пакетов для соответствующей версии:

• ESXi670-VMKUSB-NIC-FLING-20124247-offline_bundle-11613968
• ESXi650-VMKUSB-NIC-FLING-20123976-offline_bundle-11613344

Делается это следующей командой:

esxcli software vib install -d /path/to/the/offline/bundle

После установки нужно перезагрузить хост VMware ESXi, после чего устройство USB NIC будет автоматически смонтировано как, например, vusb0.

Скачать USB Network Native Driver for ESXi можно по этой ссылке.

Для многих пользователей публичного облака VMware vCloud on AWS одним из первых возникает вопрос - как предоставить доступ из виртуальной машины в сети Compute Network в сеть SDDC Management Network, например, для целей управления сервисами vCenter или другими службами виртуального датацентра?

Также этот вариант использования может быть востребован, когда вам требуется доступ к управляющим компонентам посредством таких интерфейсов, как PowerCLI, или развертывание виртуальных сервисов с помощью утилиты OVFTool. Вильям Лам написал об этом хорошую статью, и мы приведем здесь ее основные моменты.

Естественно, что для целей обеспечения безопасности в облаке, эти две сети по умолчанию разделены. Первое, что вам нужно сделать - это понять, с каким типом решения NSX для управления сетью вы работаете (NSX-T или NSX-V). Сделать это можно с помощью вот этой статьи.

Процедура для NSX-V

В среде NSX-V вам нужно настроить IPsec VPN между компонентами Management Gateway (MGW) и Compute Gateway (CGW) перед тем, как заработает коммуникация между сетями.

Для настройки VPN для компонента Management Gateway нажимаем Add VPN в консоли VMC и вводим требующуюся информацию сетевой идентификации (публичный IP удаленного шлюза, параметры удаленной сети и ключи), что должно отражать конфигурацию Compute Gateway (остальные настройки можно оставить по умолчанию).

Далее надо настроить VPN для Compute Gateway путем выполнения тех же шагов, что и в предыдущем абзаце, только указав конфигурацию шлюза Management Gateway. После того, как настройки обеих VPN будут сохранены, начнет отображаться статус "Partially Connected". Потом нажимаем ссылку Actions в правом верхнем углу, выбираем Edit и сохраняем настройки еще раз, чтобы на обоих шлюзах показался статус "Connected":

Теперь надо настроить сетевой экран Compute Gateway Firewall, чтобы разрешить исходящие соединения в SDDC Management Network по порту 443 для требуемых ВМ (этот порт используется для vSphere Client, а также для доступа через средства OVFTool и PowerCLI).

В приведенном ниже примере машина имеет адрес 192.168.1.4, и мы хотим позволить ей общаться с сетью 10.2.0.0/16 через порт 443:

Теперь нужно добавить в фаервол Management Gateway Firewall правила для разрешения входящих соединений для vCenter Server и хостов ESXi по порту 443 от наших определенных ВМ. Здесь все точно так же - указываем IP машины 192.168.1.4, и нам нужно добавить 2 правила для входящего трафика для разрешения коммуникации со средствами управления виртуальной инфраструктурой:

После этого вы можете залогиниться в виртуальную машину и использовать средства управления платформой vSphere, например, применять утилиту импорта виртуальных модулей OVFTool, как рассказано тут.

Процедура для NSX-T

В среде NSX-T вам не нужно создавать VPN для получения функциональности маршрутизации, которая изначально заложена в маршрутизаторе T0, ведь обе сети Management и Compute Network присоединены к T0. Между тем, правила сетевого экрана добавлять, конечно же, нужно.

В решении NSX-T используются сущности Inventory Groups, чтобы сгруппировать набор виртуальных машин и/или IP-адреса/сети, которые можно использовать при создании правил сетевого экрана.

Создаем две Inventory Groups для нашей Compute Group - одну для нашей виртуальной машины и одну для того, чтобы представлять сеть Management Network. Идем в Groups и в левой части выбираем пункт "Workload Groups", где создаем 2 группы:

• Windows10 с Member Type вида Virtual Machine и указываем ВМ из инвентаря.
• VMC Management Network с Member Type вида IP Address и указываем сетевой диапазон 10.2.0.0/16.

Теперь нужно создать еще одну Inventory Group для нашей Management Group, которая будет отражать ВМ, для которой мы хотим сделать доступ. Чтобы это сделать, идем в Groups, выбираем "Management Groups" и создаем следующую группу:

• Windows10 Private IP с Member Type вида IP Address и указываем частный IP-адрес ВМ (в данном случае это 192.168.1.2).

Не забывайте нажать кнопку Publish, чтобы сохранить и применить правило сетевого экрана.

Теперь нужно создать правило сетевого экрана, чтобы разрешить Compute Gateway исходящие соединения к SDDC Management Network по порту 443 для нужных ВМ. Идем в Gateway Firewall и выбираем "Compute Gateway", где создаем новое правило, которое отражает группу Windows 10 как источник и группу VMC Management Network как назначение, а в качестве сервиса выбираем HTTPS (помним также про кнопку Publish).

Теперь надо создать правила на уровне Management Gateway, чтобы разрешить входящие соединения к хостам vCenter Server и ESXi по порту 443 из нужных нам ВМ. Идем в Gateway Firewall, слева выбираем "Management Gateway", затем создаем правило, которое отражает группу Windows 10 как источник, а в качестве группы назначения указываем vCenter и ESXi (сервис ставим также HTTPS):

После выполнения этой процедуры вы сможете залогиниться в ВМ Windows и использовать утилиту OVFTool для импорта/экспорта ВМ в ваш виртуальный датацентр (см. также данную процедуру здесь).

Если все было сделано правильно, вы должны иметь возможность доступа к интерфейсу vSphere Client из нужной вам ВМ, а также возможность выполнять сценарии PowerCLI и использовать утилиту OVFTool, как показано на скриншоте ниже:

Совсем недавно мы писали о новых возможностях решения VMware NSX-T 2.4, которое предназначено для сетевой виртуализации и агрегации виртуальных сетей датацентров, работающих на базе гибридной среды гипервизоров и контейнеров приложений.

Также у VMware есть продукт vRealize Network Insight, который позволяет системным и сетевым администраторам, а также администраторам информационной безопасности, следить за сетевым взаимодействием в рамках виртуальной инфраструктуры и предпринимать действия по ее защите.

Ну и, конечно же, многие из вас помнят решение AppDefense, анонсированное на VMworld 2017. Оно реализует новую модель защиты приложений в виртуализованных и облачных средах. Суть технологии AppDefense заключается в том, что она изучает нормальное поведение операционной системы и приложений при обычных условиях, а в случае выявления отклонений от этого состояния, оповещает об этом администратора и автоматически предпринимает некоторые шаги по защите окружения.

Использовав наработки этих трех продуктов за последние годы, компания VMware на днях анонсировала новое решение - первый в отрасли Service-defined Firewall.

Это решение основано на подходе по микросегментации приложений с точки зрения защиты виртуальной среды (см. service insertion и guest introspection), что подразумевает анализ сетевой активности на уровне приложения, при этом мониторинг ведется извне гостевой ОС на уровне гипервизора (данные берутся из NSX или напрямую с серверов ESXi), что позволяет исключить манипуляции средствами обнаружения вторжений, которые могут быть выполнены программным обеспечением внутри ОС.

Но главная штука VMware Service-defined Firewall - это возможность создания политик на уровне приложений/микросервисов, а не сетевых компонентов (серверов/ОС/портов). Это существенно упрощает ввод в эксплуатацию новых сервисов с точки зрения организации их защиты, а также обслуживания при перемещении виртуальных машин внутри датацентра и между ЦОДами.

Традиционная защита ИТ-инфраструктуры строится на базе обеспечения безопасности приложений, находящимися за сетевыми экранами, то есть защищается только сетевой периметр. При этом часто вектор атаки расположен внутри инфраструктуры, где вредоносное ПО сначала изучает ее состав и структуру, а потом начинает распространяться в датацентре, используя его уязвимые места.

VMware Service-defined Firewall позволит использовать новый подход к защите сетевой инфраструктуры предприятия за счет анализа приложений внутри периметра ЦОД (internal network firewalling), где наблюдение за сервисами происходит на уровне гипервизора и на седьмом уровне модели OSI (L7 packet inspection), без агентов в гостевых ОС, при этом используется модель Zero Trust (то есть изначально нет доверия ни одному компоненту в сети, считается, что атака может прийти откуда угодно, через любое сетевое соединение).

Суть защиты заключается в наблюдении за всеми приложениями датацентра, определении их "хорошего" поведения и далее детектировании отклонений от их повседневной активности, что влечет за собой оповещение администратора, который уже предпринимает действия по устранению угроз. При этом VMware Service-defined Firewall сам способен сгенерировать нужные политики для защиты приложений.

Такая модель обладает неоспоримым преимуществом перед системами с агентами, где вредоносное ПО может получить контроль над этими агентами. Также еще один плюс VMware Service-defined Firewall - это чисто программная реализация. В современном мире программно-аппаратные сетевые экраны сложно масштабируются, а также есть проблемы с управлением ими, так как приложение в виртуальной инфраструктуре может перемещаться между серверами и даже между датацентрами.

Для анализа подозрительных активностей используется Application Verification Cloud, который собирает информацию из миллионов виртуальных машин по всему миру и использует методы машинного обучения для определения нормального поведения микросервисов и их вариаций, а также выявления отклонений от нормальных показателей.

Что интересного можно почитать на тему VMware Service-defined Firewall:

• Основная страница VMware Service-defined Firewall
• Отчет Validation Report of the Service-Defined Firewall by Verodin
• Лабораторная работа VMware NSX Micro-Segmentation Hands-on Lab
• Документ Enabling Zero Trust Security Through Network Virtualization And MicroSegmentation
• Статья Micro-segmentation with Service Insertion
• YouTube-канал о VMware NSX

Видео про возможности NSX-T 2.4, которые будут использованы в Service-defined Firewall:

Service-defined Firewall в действии и консоль AppDefense:

На днях компания VMware выпустила обновление решения для виртуализации настольных ПК предприятия VMware Horizon 7.8. Одновременно с этим релизом было выпущено и решение VMware Unified Access Gateway (UAG) 3.5, представляющее собой шлюз для доступа к инфраструктуре Workspace ONE и Horizon.

Шлюз используется для безопасного доступа внешних авторизованных пользователей ко внутренним ресурсам рабочей области Workspace ONE, а также виртуальным десктопам и приложениям Horizon. Напомним, что о версии UAG 3.4 в начале этого года мы писали вот тут.

Давайте посмотрим, что нового появилось в VMware UAG версии 3.5:

• Поддержка Unified Access Gateway Powershell для облачных инфраструктур Microsoft Azure и Amazon AWS. Подробнее можно узнать вот тут и из видео выше.
• Поддержка замены сертификатов SSL для PSG (PCoIP Secure Gateway) .
• Расширенный мониторинг внешнего балансировщика UAG за счет использования HTTP/HTTPS GET или файла favicon.ico теперь охватывает все edge-сервисы.
• Теперь не требуется отдельно указывать лицензию UAG (Standard, Advanced или Enterprise) для Workspace ONE и Horizon - все возможности UAG доступны для данных изданий.

Скачать VMware Unified Access Gateway 3.5 можно по этой ссылке. Инструкция по развертыванию решения в облачной среде доступна тут.

Мы часто писали о решении VMware vRealize Network Insight (vRNI), которое позволяет системным и сетевым администраторам, а также администраторам информационной безопасности, смотреть за сетевым взаимодействием в рамках виртуальной инфраструктуры и предпринимать действия по ее защите.

Также с помощью vRNI можно найти 3 типа отклонений для виртуальных машин, работающих непрерывно в виртуальной инфраструктуре:

• Outliers - девианты по трафику в рамках группы ВМ по сравнению с остальными членами группы.
• Thresholds - машины, которые превысили пороговые значения по трафику или сбросу пакетов.
• Top Talkers - самые потребляющие сетевые ресурсы машины в каком-то аспекте мониторинга.

Сегодня мы рассмотрим ситуацию, когда с помощью vRNI можно обнаружить девиантов по трафику (Outliers) в группе виртуальных машин, выполняющих одинаковую функцию. К таким машинам можно отнести, например, веб-серверы, размещенные за балансировщиком и принимающие на себя в среднем одинаковую нагрузку.

Если один из серверов начинает существенно отклоняться (например, отдавать трафика намного больше чем остальные), то это может говорить либо об ошибке в конфигурации балансировщика, либо о каких-то проблемах на этом веб-сервере. Также к таким сервисам можно отнести серверы DNS, Active Directory, кластеры серверов SQL и другие масштабируемые сервисы.

Помимо получения нотификаций о девиантах по SNMP или email, их поведение можно визуализовать на графиках. Это позволит вам сразу понять, какой из серверов ведет себя не как остальные, чтобы сразу приступить в выяснению источника проблемы:

Здесь мы видим, что виртуальная машина cmbu-sc2dc-01 на порту 53 имеет большой поток трафика, гораздо больше, чем остальные, поэтому и попала в категорию "Outliers" на панели справа.

Для мониторинга такого поведения вы можете выбрать один или несколько портов, а также направление трафика (входящий/исходящий), так как есть сервисы, которые в основном принимают данные (например, обработчики), а есть, которые преимущественно отдают (веб-серверы, DNS и т.п.).

Чтобы создать группу Outliers для мониторинга, нужно в консоли vRNI пойти в меню Analytics и там открыть раздел Outliers:

Далее вы увидите список всех настроенных групп Outliers. Там вы увидите, сколько девиантов в каждой группе было обнаружено, какие связанные с ними события произошли, а также информацию о группе (сколько ВМ, их IP и т.п.), также вы увидите, когда были обнаружены эти отклонения.

Для создания новой группы, в правом верхнем углу надо нажать ADD и установить все необходимые настройки:

Здесь они означают следующее:

1. Имя группы.
2. Масштаб наблюдения (application tier, NSX Security tag и т.п.).
3. Для уровня приложения (application tier) нужно выбрать само приложение и его ярус (tier).
4. Метрика - total traffic (MB, GB и т.п.), число пакетов или сессий, либо объем трафика в секунду.
5. Направление обнаруживаемого трафика (incoming, outgoing, both).
6. Направление трафика в датацентре: north-south (интернет-трафик), east-west (внутренний трафик датацентра), либо оба направления.
7. Порты назначения - можно мониторить все используемые порты, либо выбранные. Но пока есть лимит 20 портов, если он будет превышен, то их надо будет вводить вручную.
8. Чувствительность алгоритма обнаружения (low, medium, high).
9. Когда все установлено, vRNI сгенерирует превьюшку результатов на графике, включающем в себя настроенные сетевые потоки.

Если превью вас устроило, то просто нажимаете Submit и добавляете новую группу в систему мониторинга.

Как только обнаруживается Outlier, для него создается открытое событие (Event), оно продолжает висеть в открытых, пока отклонение продолжает существовать. Как только все возвращается в норму, событие закрывается, однако остается в архиве, чтобы администратор знал о происходящем.

В общем, vRNI, хотя бы только с этой стороны - полезная штука!

Источник.

Недавно VMware объявила о большом обновлении своего решения для сетевой виртуализации и агрегации виртуальных сетей датацентров, работающих на базе гибридной среды гипервизоров и контейнеров приложений Kubernetes/Docker - VMware NSX-T 2.4 (кстати, вот видео об отличии этого решения от NSX-V для vSphere).

Это уже пятое обновление данной платформы, при этом для компании это большой анонс, так как продукт существенно расширяет возможности по обеспечению сетевой управляемости гибридных (облачных и онпремизных) инфраструктур и обеспечивает полную поддержку протокола IPv6.

Напомним, что прошлая версия NSX-T 2.3 вышла в сентябре прошлого года. С тех пор многое изменилось, поэтому давайте посмотрим, что нового (из основного) появилось в NSX-T 2.4:

1. Упрощение установки, конфигурации и ежедневного оперирования.

В этой области появилось 3 основных улучшения:

• Новый виртуальный модуль NSX manager appliance, который поддерживает кластерную конфигурацию до 3 узлов, каждый из которых выполняет функции обеспечения политик и контроля сетевой инфраструктуры. Это дает высокий уровень отказоустойчивости. Также установщик имеет модули Ansible для упрощения процедуры автоматизированной установки и настройки рабочих процессов.
• Радикально упрощенный пользовательский интерфейс, где еще более продуманы значения по умолчанию и уменьшено число экранов и кликов для ежедневных операций.
• Контекстный поиск с мощными функциями по автозаполнению, что упрощает решение проблем из консоли NSX-T.

Вот в качестве примера окно обзора конфигураций - видно, насколько все стало более наглядным и удобным для восприятия:

2. Декларативная модель политик.

Эта новая модель распространения конфигураций и настроек безопасности позволяет пользователю определить, что необходимо для обеспечения связности и безопасности, вместо того, чтобы задавать, как нужно пройти по шагам процесс настройки.

Вместо детализированных вызовов API, которые должны быть выполнены в строго определенной последовательности, NSX Manager теперь принимает на вход декларативное описание политики в виде одной API команды с данными в формате JSON, которое несложно понять (а значит, увеличивается прозрачность операций).

Также такой подход уменьшает число вероятных ошибок, связанных с последовательностью или полнотой команд API. К тому же, он позволяет легко переносить описание политики для приложения между платформами. В видео ниже показан реальный пример использования таких декларативных политик (с семнадцатой минуты):

3. Расширенные возможности безопасности.

Новый релиз NSX продолжает развивать концепцию микросегментации приложений. В этом направлении появились следующие новые возможности:

• Контекстный сетевой экран, работающий на уровне 7 модели OSI.

• Фаервол на базе сетевой идентичности приложения.
• Белые списки адресов FQDN/URL на распределенном фаерволе (DFW) для разрешения определенного типа трафика ВМ к определенным адресам или хостам в датацентре:

• Возможность анализа трафика на уровне гостевой ОС (guest introspection).
• Возможности E-W service insertion (контроль трафика в пределах датацентра средствами сторонних IDS/IPS-систем).

Также в NSX-T 2.4 существенно был улучшен механизм аналитики и визуализации данных, а также появилась поддержка Splunk и VMware vRealize Log Insight.

Ну а о новых возможностях обеспечения сетевой безопасности можно узнать из этого видео:

4. Высокий уровень масштабируемости, надежности и производительности.

Прежде всего, в рамках новых возможностей в этой категории, у NXS-T появилась полноценная поддержка протокола IPv6. Кластер NSX-T теперь состоит из 3 полноценных и равноправных узлов, что дает расширенные возможности по масштабированию решения и обеспечению надежности.

В одном NSX-домене теперь может быть более 1000 хостов с полной поддержкой разделения сетевой инфраструктуры между различными клиентами уровня виртуального датацентра.

5. Партнерства и новые возможности для пользователей.

Со стороны NSX-T поддержка продуктовой линейки VMware и партнерских решений была существенно расширена. Теперь такие решения, как Kubernetes, VMware PKS, Pivotal Application Service (PAS) и Red Hat OpenShift в различной мере поддерживаются NSX-T, и их поддержка будет только расширяться.

Конечно же, обеспечивается поддержка облачных решений, особенно VMware Cloud on AWS и нативных облачных нагрузок через VMware NSX Cloud. Также продукт NSX-T включен в состав таких платформ, как VMware Cloud Foundation, VMware vCloud NFV, а в будущем и в AWS Outposts и VMware Cloud Foundation for EC2.

Более подробно о новых возможностях VMware NSX-T 2.4 рассказано в Release Notes. Скачать продукт можно по этой ссылке. Вот еще несколько полезных ресурсов:

• NSX Hands-On-Lab (HOL)
• Канал по NSX на YouTube
• Документация

На сайте проекта VMware Labs появилась интересная и полезная некоторым администраторам vSphere штука - USB Network Native Driver for ESXi. Это нативный драйвер для сетевых адаптеров серверов, которые подключаются через USB-порт.

Такой адаптер можно использовать, когда вам необходимо, например, подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов. В каких-то еще случаях подключение такого адаптера может помочь, чтобы получить еще одно сетевое соединение без необходимости перезагружать сервер (и так же просто отключить его).

На данный момент драйвер поддерживает 3 самых популярных чипсета на рынке:

• ASIX USB 2.0 gigabit network ASIX88178a
• ASIX USB 3.0 gigabit network ASIX88179
• Realtek USB 3.0 gigabit network RTL8153

А вот, собственно, и сами поддерживаемые адаптеры:

Надо отметить, что это сравнительно недорогие устройства, которые может позволить себе каждый администратор платформы vSphere.

Установка драйвера производится одной командой:

esxcli software vib install -d /path/to/the offline bundle

Затем нужно будет перезагрузить хост VMware ESXi, после чего устройство USB NIC будет автоматически смонтировано как, например, vusb0. Но чтобы приаттачить такой NIC к виртуальному коммутатору vSwitch, придется добавить в /etc/rc.local.d/local.sh такой скрипт:

vusb0_status=$(esxcli network nic get -n vusb0 | grep 'Link Status' | awk '{print $NF}')

  count=0

  while [[ $count -lt 20 && "${vusb0_status}" != "Up" ]] ]

  do

sleep 10

count=$(( $count + 1 ))

vusb0_status=$(esxcli network nic get -n vusb0 | grep 'Link Status' | awk '{print $NF}')

done

if [ "${vusb0_status}" = "Up" ]; then

  esxcfg-vswitch -L vusb0 vSwitch0

  esxcfg-vswitch -M vusb0 -p "Management Network" vSwitch0

  esxcfg-vswitch -M vusb0 -p "VM Network" vSwitch0

  fi

Драйвер работает с VMware vSphere 6.5 и 6.7. Скачать его можно по этой ссылке.

Это гостевой пост нашего партнера - компании ИТ-ГРАД, предоставляющей услугу аренды виртуальных машин из облака по модели IaaS.

Что изменилось с наступлением DNS Flag Day? Еще до недавнего времени этот вопрос активно обсуждали в Рунете. Одни полагали, что большинство государственных сайтов и других веб-ресурсов могут стать недоступными, другие – были уверены, что ничего существенного не произойдет. В целом, становилось понятно, что сложности возникнут лишь в том случае, если DNS-серверы окажутся неготовыми отвечать на запросы EDNS. Но эксперты заранее поспешили всех успокоить. К тому же результаты исследования по ситуации в российских национальных доменных зонах .ru и .рф были довольно позитивными – процент DNS-серверов, некорректно отвечающих на запросы по обновленной схеме, оказался ничтожно мал.

Чем не угодил старый добрый DNS

Протокол DNS действительно довольно старый. Его придумали в начале 80-х годов и в условиях современной жизни он давно перестал отвечать требованиям времени. Очевидно, что система доменных имен требует развития и не может оставаться в первозданном виде. Протокол имеет множество проблем, с которыми давно столкнулись производители программного обеспечения. К тому же по сей день остаются не решенными отдельные вопросы безопасности, да и многие функции, которые требовалось реализовать, до сих пор не реализованы. Большое количество DNS-серверов до сих пор не поддерживают необходимые требования в работе с современными информационными системами, что является барьером к принятию новых технологий. И хотя возможности DNS пытались как-то расширить, это ровным счетом не сильно повлияло на текущую ситуацию.

Какие изменения происходили? В 1999 году придумали расширение EDNS0, благодаря которому работает механизм DNSSEC. Если кратко, DNSSEC умеет вычислять «подмену», то есть узнавать, кто ответил на DNS-запрос: легитимный источник либо же кто-то другой, не имеющий к нему никакого отношения. Это хоть и стало некой подвижкой к переменам, но в целом не решило всех проблем. Читать статью далее->>

В прошлом посте мы рассказывали о IOchain - цепочке прохождения пакетов через сетевой стек хоста VMware ESXi, а в этом остановимся на некоторых утилитах, работающих с этим стеком и помогающих решать различного рода сетевые проблемы.

Прежде всего, при решении проблем соединений на хосте ESXi нужно использовать следующие средства:

• Консольная утилита esxtop (представление network)
• ping / vmkping
• traceroute

Но если хочется углубиться дальше в сетевое взаимодействие на хосте, то тут могут оказаться полезными следующие утилиты:

• net-stats
• pktcap-uw
• nc
• iperf

1. Net-stats.

Чтобы вывести весь список флагов этой команды, используйте net-stats -h, а вот для вывода детальной информации о номерах портов и MAC-адресах всех интерфейсов используйте команду:

net-stats -l

С помощью net-stats можно делать огромное количество всяких вещей, например, проверить включены ли на интерфейсе vmnic функции NetQueue или Receive Side Scaling (RSS) с помощью команды:

net-stats -A -t vW

Далее нужно сопоставить вывод блока sys для нужного интерфейса и вывода команды:

vsish -e cat /world/<world id>/name

2. Pktcap-uw.

Эта утилита совместно с tcpdump-uw захватывать пакеты на различных уровнях. Если tcpdump-uw позволяет захватывать пакеты только с интерфейсов VMkernel, то pktcap-uw умеет захватывать фреймы на уровне виртуального порта, коммутатора vSwitch или аплинка.

В KB 2051814 подробно описано, как можно использовать утилиту pktcap-uw. На картинке ниже представлен синтаксис использования команды, в зависимости от того, на каком уровне мы хотим ее применить:

• Фильтрация пакетов для выбранного MAC-адреса:

pktcap-uw --mac xx:xx:xx:xx:xx:xx

• Фильтрация пакетов для выбранного IP-адреса:

pktcap-uw --ip x.x.x.x

• Автоматическое исполнение и завершение pktcap-uw с использованием параметра sleep:

pktcap-uw $sleep 120; pkill pktcap-uw

• Ограничить захват заданным числом пакетов:

pktcap-uw -c 100

• Перенаправить вывод в файл:

pktcap-uw -P -o /tmp/example.pcap

3. NC

NC - это олдскульная Linux-команда NetCat. Она позволяет проверить соединение по указанному порту, так как telnet недоступен на ESXi. Например, так можно проверить, что можно достучаться через интерфейс iSCSI по порту 3260 до системы хранения:

nc -z <destination IP> 3260

В KB 2020669 вы можете найти больше информации об этой команде.

4. Iperf

Эта утилита предназначена для контроля пропускной способности на интерфейсе. Она используется механизмом vSAN proactive network performance test, который доступен в интерфейсе vSAN. Поэтому при ее запуске вы получите сообщение "Operation not permitted". Чтобы она заработала, нужно создать ее копию:

cp /usr/lib/vmware/vsan/bin/iperf3 /usr/lib/vmware/vsan/bin/iperf3.copy

По умолчанию утилита работает на портах, которые запрещены фаерволом ESXi, поэтому во время работы с ней нужно его потушить (не забудьте потом его включить):

esxcli network firewall set --enabled false

Теперь можно использовать эту утилиту для замера производительности канала (флаг -s - это сервер, -c - клиент):

/usr/lib/vmware/vsan/bin/iperf3.copy -s -B 192.168.200.91

/usr/lib/vmware/vsan/bin/iperf3.copy -c 192.168.200.91

Результат будет похожим на это:

Больше об использовании утилиты iperf3 вы можете узнать вот тут.